When transmitting data from a server to a computer system, or from a computer system to another computer system, it is not guaranteed that 100% of the data requested by the user will arrive. Often times some of the data is lost in the transmission or is never sent at all.
Accordingly, methods have been provided for verifying proper receipt of data and when, for instance, a packet in a packetized data stream is not received, for requesting retransmission. In these methods, a data verification layer in a communication protocol stack tracks the received packets and requests retransmission if a packet does not arrive as expected.
As recognized herein, current standards for tracking data often contain overhead and latency which is too high for certain data streaming environments, such as telephony. Nonetheless, a receiver must buffer data before sending it on to higher levels in the protocol stack while waiting for a retransmitted packet. The length of the buffer in current systems is predefined in an attempt to balance the need to wait long enough for a dropped packet to be retransmitted and received, so as to avoid missing the retransmitted packet when the rest of the data is passed on up the protocol stack, but to also avoid waiting longer than necessary. A buffer length that is too long makes the system seem sluggish (i.e. non-responsive) to the user, while a buffer length that is too short allows stuttering of data (such as video frames) that is presented to the user if the retransmission of certain packets is required. The inaccuracies of estimated buffer length and the visible consequences to the user can be frustrating. The present system is presented in response to the above critical observations.